I don't understand the problem tbh. The Card component would set the padding for a class it defines with in its own scope and sets on the Button component?

<style>
.button {
  padding: 5px;
}
</style>

<template>
  <!-- this is the Card component's template -->
  <div><Button class="button" /></div>
</template>

I'm not sure how we need to be careful which selectors we use as the Card component can only use the .button selector anyway as it cannot even know what the class names in the <Button> component are?

I guess I need to find a better way to explain this, essentially the issue is that if the Button component has 2/3 selectors then the specificity will be higher and therefore we would need to be careful with the selectors in the Card component to make sure the base styles are being overridden

But this means that the Card component is now implicitly coupled to an implementation detail in the Button component (the fact that it sets the data-button attribute on the button it renders). I'd argue this is an anti-pattern and if you want to change the buttons, you should set a class?

If you wanted to set the padding for all Buttons at any nesting level within the Card component, isn't that what CSS variables are for?

I had the issue of trying to make this example as simple as possible so that the focus could be the thing that I wanted to showcase but I think it is too simple in this case. The main issue that I am failing to point out is that you might not have a way to add a class to that component directly; if it is 3+ components deep then you wouldn't want to have to pass a class all the way through those components. So in this scenario I can see why this doesn't make sense and I need to think of a better way to showcase it.

But still, isn't setting the style for a component 3 levels down the tree based on a [data-] selector an anti-pattern since you're specifically using that technique to bypass CSS encapsulation? Isn't this what CSS variables are for so that the component can be explicit about what style properties are supposed to be overridden (and thus part of its public API)?

We definitely could use a CSS variable here, and I think that's another flaw with this example, because overriding padding is easily done in that way, but if we wanted to override multiple things or if we needed to drill down deeper to get to the property then it wouldn't work as well.

I'll add in the example with css variables and then explain the benefits and drawbacks

minor changes like not setting data-button anymore in the Button component :)

In this scenario the data-button attribute would be one of the foundational blocks suggested, so it would have big consequences to remove it for sure. But you could put it on par with the class: the button component would definitely not look as intended without it

Sure, the button would look wrong without the data-button attribute but that's not the question (you can imagine a refactoring where the attribute is renamed and the component's own styles are changed accordingly). The issue here is that the data-button attribute becomes part of the component's public API and all of the component's own/internal styles become part of it's API as well in a way since you're allowing all of the styles to be changed via selectors based on the data-button attribute – whatever you change, you'll need to make sure it's consistent with other styles (e.g. aspect ratios or whatever; if you're exposing a CSS variable you can allow that to be changed and then define styles that depend on the value of the variable, thus enforcing consistency like width is always twice the height or whatever).

In short, what I'm saying is I have the feeling that this post recommends a pattern, I'd consider an anti-pattern actually – of course I might still be misunderstanding sth.

I think you touch on an interesting point about what should be considered the component's public API. I'm thinking I've just framed it wrong, perhaps this isn't a suggestion for how to build the foundation of your app, but rather a way to expose the ability to update styles in a mature app without having to refactor everything

I would change the indent with 2 spaces here.